A “clean file snapshot” is a copy of a database, or a portion thereof, that reflects all changes made to the database as of a specific time, and no changes made to the database after the specific time. The specific time before which the copy reflects all changes, and after which the copy reflects no changes, is referred to as the “snapshot time” of the copy. For the purposes of creating a clean file snapshot, “changes made to the database” includes all changes made to the database, regardless of whether the changes have been “committed”.
One way to make a clean file snapshot of a database is to                stop any changes to the database        flush to disk all dirty buffers to bring the disk copy of the database up-to-date, and        make a backup copy of the up-to-date copy of the database        
After the backup copy of the database has been made, the original copy may be made available again for new changes. The backup copy thus created represents a clean file snapshot because the backup copy reflects all changes made up to a particular point in time, and no changes made after the particular point in time. In this example, the snapshot time of the backup copy would be the time at which the database system stopped allowing changes to the database.
Unfortunately, preventing transactions from updating the database until the data files are copied can result in an unacceptable delay, impairing both performance and availability of the database. However, if transactions are allowed to make changes during the file copy process, then the resulting backup copy will be “fuzzy” rather than clean. Specifically, because updates are not prevented, updates may be made, after the snapshot time, to a portion of the database that has not yet been copied. During the copy operation, those updates will be copied to the backup copy.
The foregoing is an example of how a “fuzzy” backup of the database can be created without taking the database offline. The backup is “fuzzy” because the copied files are not guaranteed to only have changes that occurred before a given time. After a “fuzzy” backup is made, the backup may be “cleaned up” to make a clean file snapshot (e.g. by applying necessary redo). However, such cleanup operations can become complicated and error prone.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.